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The  DoD  Acquisition  Landscape 


the  Department  of  Defense 
acquisition  system  is  simply  not  well 
suited  to  exploit  information  technology. 
It  is  still  tied  to  projecting  distant  threats 
and  creating  programs  to  acquire  major 
systems  that  take  decades  to  field.  In 
short,  it  rewards  freezing  programs  at  an 
early  stage  and  penalizes  change.” 
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(Admiral  Blair,  2001) 


DoD  IT  Acquisition  Needs 


The  DoD  needs  IT  systems  that: 

Maximize  IT  capabilities 

Achieve  high  interoperability  with 
multiple  systems 

Reach  the  field  rapidly 

Adapt  to  changing  user  needs 

Adapt  to  new  technology 
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The  Need  for  Rapid  Acquisition 


DoD  technology  growth  is  dependent  on  its  budget 
growth  (Augustine’s  Law). 


Technology  Growth  =  67%  /  year  (Moore’s  Law) 

Augustine  DoD  Growth  =  5-7%  /  year 

The  difference  between  Hi-tech  &  DoD:  growth  rates  =  60% 


Moore's  Law 
(Technology) 


Augustine's  Law 
(DoD) 


Moore’s  Law 


This  difference  represents  growth  of 
or  .  It  is  an 


Risk  due  to 
obsolescence 


Moore’s  Law  f 
(Technology)/ 


Augustine’s  Law 
(DoD) 


The  gap  between  Hi-tech 

Moore  growth  and  Augustine  DoD 
growth  is  an 
We  shall  call  it 
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Fiscal  and  Process  Oversight 


DoD  IT  acquisitions  must  also 
comply  with  oversight  from  the: 

Office  of  the  Secretary  of  Defense 
Office  of  Management  and  Budget 
General  Accounting  Office 
U.S.  Congress 
U.S.  Taxpayers 
Clinger-Cohen  Act  of  1996 
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The  Combined  Challenge 


Increase  the  speed  of  developing 
and  fielding  IT  systems... 

While  maintaining  and  improving 
system  effectiveness... 

Through  a  process  that  meets 
fiscal  and  process  requirements. 
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Looking  Forward 


“I  do  not  know  what  all  our  warfighting 
requirements  in  the  21st  century  will  be. 
However,  if  we  have  an  adaptive  system 
that  can  bring  new  technology  into  the 
field  quickly,  addressing  today’s  needs, 
we  will  have  a  system  that  meets  the 
missions  of  the  future  as  they  become 
clearer.” 

(Admiral  Blair,  2001) 
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Comparing  Two  Approaches 


Incremental  Development  (ID) 

Evolutionary  Development  (ED) 

The  DoD  is  increasingly 
encouraging  the  use  of  ED. 

In  practice,  however,  the  ID 
approach  is  more  common. 
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Incremental 

Development 


“Top-Down” 

§  Complete  set  of 
requirements  written 
first 

§  Developed  in  multiple 
phases 

§  Possible  intermediate 
deliverables 


Evolutionary 

Development 


“Spiral” 

§  Broad  goals  and 
some  requirements 
written  first 

§  Developed  in  multiple 
phases 

§  Multiple  intermediate 
deliverables,  which 
reflect  changed  and 
refined  requirements 
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Potential  Benefits  of  ED 


Provides  quality  feedback  on 
intermediate  products 

Allows  for  early  risk  avoidance  and 
error  correction 

Reduces  the  overall  cycle  time 
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Potential  Problems  with  ED 


Unnecessary  overhead  if  the 
complete  requirements  are  well- 
known  at  the  start  of  the  project. 

Loss  of  focus/confusion  due  to: 

u  A  developer  involved  with  multiple, 
concurrent  ED  projects 

u  A  split  development  team 
attempting  to  produce  multiple 
spirals  at  the  same  time 
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Will  ED  V\fork  in  the  DoD  Setting? 


Even  if  DoD  makes  greater  use  of 
ED,  the  process  will  differ  from 
commercial  ED. 

There  will  be  differences  in  the 
process  because  there  are 
inherent  differences  in  the  DoD 
and  commercial  environments. 
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DoD  vs.  Commercial  Acquisition 


DoD  is  involved  with  more 
oversight  organizations. 

DoD  is  subject  to  acquisition  laws 
and  guidelines. 

Rate  of  requirements  change  is 
greater  in  the  commercial  world 
than  in  the  DoD. 

Most  ED  projects  have  users  and 
developers  at  the  same  site  -  this 
is  not  always  feasible  for  the  DoD. 
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Additional  ED  Challenges 


Much  time/effort  are  needed  to: 
u  Communicate  requirements 
u  Monitor  progress 

If  in-house  and  contractor  teams 
develop  different  parts  of  the 
system,  problems  may  result 
with  versioning,  interface, 
interoperability,  and  architecture 
mismatch. 
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Proceed  with  Caution. . . 


ED  offers  many  potential  benefits. 

However,  by  adopting  greater  use 
of  ED,  DoD  acquisition  problems 
may  not  go  away. 

It  is  possible  that  in  some  areas, 
we  may  get  into  even  larger 
problems. 
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Issues  to  Consider 

Securing/planning  for  funding 
Defining  requirements 
Determining  spirals 
Determining  cycle  time 
Writing  the  contract 
Testing  the  IT  product 
Providing  sponsorship 
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Funding  an  ED  Project 


ED  is  well  suited  to  small  initial 
budgets,  with  additional  funding 
approved  only  when  the  current 
phase  is  successful.  This: 

u  Ensures  that  only  the  most 
essential  features  are  developed 

u  Promotes  a  quality  product  at 
each  development  phase 

u  Allows  unsuccessful  projects  to 
be  cancelled  with  relative  ease 
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Funding  Issues  for  DoD 


DoD  funding  is  approved  by 
Congress  annually. 

If  the  full  project  is  not  funded  at 
the  outset,  how  can  we  know  that 
funds  will  not  be  cut  off  due  to  lack 
of  money  rather  than  lack  of 
progress? 

How  would  we  determine  the 
appropriate  amount  of  funding? 

Which  organization  would  approve 
or  cancel  a  project? 
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ED  Requirements  Definition 


ED  involves  a  tight  feedback 
circle  between  users  and 
developers 

u  Preferably  on  site 

u  Preferably  meeting  once  a 
week  (or  at  least  once  a 
month) 
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Requirements  Issues  for  DoD 


Cost  of  requirements  definition  and 
oversight  will  not  be  low  due  to 
constant  interaction  between  users 
and  developers. 

What  happens  if  users  and 
developers  are  not  located  near 
each  other? 

Can  teleconferencing  address  this 
issue  completely? 
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Spirals  &  Cycle  Time 


What  is  the  appropriate  number  of 
spirals,  and  what  is  the  appropriate 
cycle  time  for  each? 

Who  makes  this  determination? 

Too  many  spirals  =  costly 
overhead 

Too  few  spirals  =  losing  the 
benefits  of  ED 
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Contracting  Issues 


HHow  can  we  negotiate  a 

contract  with  the 
developer  given  that  we 
do  not  have  the  final 
requirements  and 
requirements  will  change 
during  the  development 
process? 
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Testing  the  ED  Product 


Testing  will  be  more  important. 

u  Each  intermediate  product  must  be 
high  quality. 

u  Each  change  must  be  subject  to 
regression  testing,  and  changes 
will  be  often  and  extensive 

u  Testing  will  take  place  throughout 
the  development  cycle,  because  it 
will  be  used  from  the  first  cycle  to 
the  last. 
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Testing  Issues  for  the  DoD 


Each  deliverable  must  meet  1-9 
and  safety  requirements. 

End-to-end  testing  is  important 
because  of  interoperability  and 
legacy  system  concerns. 

Test  scenarios  should  be 
requirements-d  riven, 
understandable,  easy  to  change, 
and  available  online  at  all  times 
during  the  system  life  cycle. 
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Sponsorship 


Each  project  must  be  sponsored. 

Commercial  projects  often  fail  if 
they  have  no  sponsor,  or  if  the 
sponsor  leaves  the  organization 
during  development. 

Parties  involved  in  the  project  may 
change;  however,  the  business 
case  for  a  project  should  serve  as 
a  sponsor. 
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Key  Goals  for  Acquisition  Reform 


Make  the  acquisition  process 
flexible,  dynamic  and  adaptive 

Reduce  the  acquisition  engineering 
development  cycle  time 
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Candidate  Approaches  (1) 


Support  both  ID  and  ED  through 
technology  and  process 
streamlining. 

Make  oversight  minimally 
invasive  by  making  several 
milestone  reviews  online  or 
requiring  simplified  data. 
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Candidate  Approaches  (2) 


Devise  a  way  for  end  users 
to  interact  with  developers 
during  the  entire 
development  and 


|  | 

^  maintenance  process. 

Give  end  users  more 

autonomy  in  making  IT 

acquisition  decisions. 
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Candidate  Approaches  (3) 


Devise  a  way  to  fund  ID/ED  projects 
when  complete  requirements  are  not 
known  at  the  beginning. 

Measure  IT  spending  effectiveness 
based  on  mission  performance  and 
improvement,  rather  than  just  the 
delivery  of  systems. 

Measure  effectiveness  of  IT  projects 
based  on  the  total  life  cycle  cost, 
including  operations  and  maintenance. 
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An  Income  Tax  Model  for  ED 


An  acquisition  process  based  on  the 
income  tax  model  may  be  beneficial: 

Gives  flexibility/autonomy  to  users 

Assures  oversight  capabilities  to 
the  OSD  and  GAO 

Makes  extensive  use  of 
technology 


8/12/2003 


35 


INCOME  TAX  MODEL 


§  Taxpayer  reports  gains 
and  losses. 

§  Taxpayer  files  annual  income 
tax  report. 


§  IRS  may  choose  to  audit  the 
taxpayer  for  a  specific  reason. 

§  IRS  may  audit  the  taxpayer  as 
one  of  several  random 
selections. 


TAXPAYER 


Acts  with  autonomy  to  generate 
income  (jobs,  investments,  etc.) 
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Key  for  Cycle  Time  Reduction 


From  both  commercial  (Extreme  Programming 
and  Agile  methods)  and  military  IT  development 
experience  (Adm.  Blair),  we  know  that  IT  cycle 
time  can  be  reduced  if 

u  Constant  and  frequent  interaction  between 
users  and  developers,  so  that  developers 
understand  the  requirements,  and  user  can 
provide  frequent  evaluation  and  feedback. 

u  Frequent  and  extensive  testing  during  the 
entire  process  including  intermediate 
deliverables. 

u  Use  a  flexible  and  loosely  coupled  design  to 
allow  changes  to  be  made  quickly. 
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Key  for  Cycle  Time  Reduction 

(continued) 


u  To  get  cycle  time  reduction,  it  is  essential  that  the 
acquisition  process  should  encourage  and  support 
interaction  between  developers  and  users,  while  at 
the  same  time  allowing  appropriate  oversight  to  be 
conducted  properly.  The  Income  Tax  model 
encourages  the  interaction  between  developers 
and  users,  while  allowing  oversight  to  be 
conducted  via  filling  up  forms  like  filling  up  income 
tax  forms.  This  model  gives  the  maximum  freedom 
to  users  and  developers  to  make  their  decisions 
(including  requirements,  design,  budget,  and  life 
cycle  decisions)  without  consulting  to  OSD,  and 
thus  minimize  all  the  unnecessary  bureaucracy. 
The  freedom  allows  users  and  developers  to  make 
rapid  and  timely  changes  during  the  acquisition 
process  to  meet  the  ever  changing  requirements  or 
to  take  advantages  of  emerging  technologies. 
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Key  for  Oversight  Management 


Give  the  Combatant  Commanders 
and  Services  increased  autonomy 

In  return,  the  Services  must: 

u  Report  their  activities  in  writing 

u  Participate  in  periodic  and  random 
audits 
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Testing  in  the  New  Approaches 

Evolutionary  development  emphasizes: 

u  Incremental  delivery  -  each  deliverable  fully 
tested,  functional,  and  ready  for  deployment. 

u  End-to-end  system  capabilities  -  not  just 
testing  individual  systems,  but  continuous 
evaluation  of  operational  scenarios, 
interoperability,  thread  analysis,  integration,  and 
information  assurance. 

u  Regression  testing  -  as  requirements 
change  during  ED,  E2E  provides  an  economical 
process  to  select  and  run  the  extensive  test 
cases  to  ensure  that  changes  do  not  create 
adverse  effects. 
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Definition 

PIR  is  the  gathering,  review,  analysis  and  reporting  of 
warfighter/user  comments  and  details  on  how  well  the 
respective  fielded  (post  Milestone  C)  IT  system  is 
operating/performing  and  supporting  the  mission 
requirements  it  was  expected  and  designed  to  do. 


do!” 
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The  Strategy 

A  Three  Phased  Approach 

Garner  CINC  Involvement 

Leverage  Existing  Exercises  and 
Operations 

Make  PIR  process  Family  of 
Systems  Centric 

Link  JFCOM’s  Requirement 
Reviews  with  PIR  assessments 
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Phased  Approach 


n  Phase  I 

u  On-site  C3I  support 
«  Create  PIR  Process 

«  Garner  Process  approval  from  OSD  stakeholders,  CINCs,  and  Service  Acquisition 
Communities 

«  Develop  short  and  long  term  funding  strategy 
u  Coordinate  with  JFCOM  and  CENTCOM/SOCOM 
«  Gain  approval  for  on-site  support 
«  Develop  MOU  between  CIO  and  CINC  sites 

nPhase  II 

u  Develop  five  year  POM  requirement  for  CINC  sustainment 
u  Coordinate  approval  for  on-site  support  for: 

«  USFK,  EUCOM,  and  PACOM  in  that  order 
«  CIO  surge  support 

nPhase  III 

u  Develop  Increase  POM  request 
u  Coordinate  approval  for  on-site  support  for: 

«  SOUTHCOM 

8/12/2003  «  SPACECOM 
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PIR’s  Answer  the 
Warfighter’s  Concerns 


n  Does  it  do  what  it  was  designed  and  expected  to  do? 
n  Did  we  get  what  we  paid  for? 
n  Has  it  been  integrated?  (DOTMLPF) 
u  Doctrine 
u  Operations 
u  Training 
u  Material 
u  Leadership 
u  Personnel 
u  Facility 

n  Are  there  any  interfacing  and/or  interoperability  issues? 
n  What  are  the  recommendations  for  product  improvements? 
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USJFCOM  -  DuL  CIO 


Partnership 


CINC  Partnership  Added 
Value 

n  Support  CINCs  in  establishing  evaluation  requirements 
within  their  Joint  Exercises  and  Operations  to  assess  newly 
fielded  systems 

n  CIO  has  a  direct  path  and  insight  into  the  CINCs  Joint 
Mission  Area  Criteria 

n  Move  the  PIR  process  from  a  system-centric  focus  to  a 
Family  of  System/Mission  centric  focus  required  by  the 
Clinger-Cohen  Act 

n  Help  CINCs  filter  evaluation  results  and  Warfighter/user 
concerns  to  the  Joint  requirements  community 

n  Provides  a  Reach  Back  Capability 
u  Government  Action  Officers 

-  Contractor  Analysts/Engineers/Developers 

-  Testing/Experience 

n  Allows  JFCOM  and  C3I  to  link  requirements  with  users. 
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PIR  Added  Value 


n 


n 


n 


n 


n 


Results  support  decisions  for  funding  product 
improvements. 

System  improvement  responsive  to  user  needs. 

Demonstrates  IT  system  oversight  mechanism. 

Demonstrates  concern  to  the  Warfighters/users  as  to 
the  IT  systems  provided  to  meet  their  mission  needs. 

System  development  to  deployment  would  be  made 
quicker. 
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The  Way  Ahead 

The  Short  Term 


Take  Strategy  to  ASD/C3I  Leadership 
u  Take  Briefing  to  AT&L 
u  Refine  Briefing  for  JFCOM 

Develop  Funding  Requirement  for  On-site  Support  to 
Implement  Phase  I  of  Strategy 
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The  Way  Ahead 


Applying  ED  to  the  DoD  IT  acquisition 
process,  directly  as  used  in  the 
commercial  world,  is  not  the  solution. 

A  more  careful,  customized  approach, 
based  on  the  income  tax  model,  holds 
much  promise  for  meeting  acquisition 
objectives: 

u  A  flexible,  shorter  acquisition  process 

u  The  production  of  effective  warfighting 
technology  for  the  21st  century. 
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